NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/7461

Internet Message Format | 1996-08-05 | 6.7 KB

Path: dnt.dialog.com!news
From: Paul Gorodyansky <[e-mail]>
Newsgroups: comp.lang.pl1,comp.lang.c
Subject: Re: PL/I and C
Date: Mon, 26 Feb 1996 11:18:15 -0800
Organization: Knight-Ridder Information, Inc.
Message-ID: <[e-mail]>
References: <4gh5ru$[e-mail]> <4gn5d8$[e-mail]> <4gril3$[e-mail]>
NNTP-Posting-Host: pc3046.corp.dialog.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0 (Win16; I)

As I said, I just found out that my posting went also to
 comp.lang.C group, in addition to PL/I group.

So, I'll be more careful and post only to a specific group, because
OUR talk was about *mainframe* C vs. PL/I, and MOREOVER, about
*business* applications, involving heavy Text Processing, not about
*systems* programming.                   ---------------

 Again, in *business* applications *Production* environment, where
   - to be 'closer to Specs',
   - to be 'easy to read' and
   - 'easy to maintain'
   - 'quicker to fix'
 is Vital, PL/I is MUCH better than C.

   All you, C guys who replied, paid TOO MUCH attention to my note
about UNIONS, but it's a MINOR thing compared to other AWFUL for
an *application* programmer  things in C that I listed.
In systems/low-level tasks C may be Perfect.

After so many replies that did not quote these MAJOR things, I am
posting to comp.lang.C group LAST time, repeating the items, that,
in my opinion, make C a *bad* choice for
  an *application* Production environment,
  where Fix time is *critical*,
  where are MANY (not ONE package for market) *different* programs,
  OFTEN to be changed due to Specs changes,
  often by several engineers, who may see *this* program and
  *this* data(Huge) FIRST time and have COUPLE hours to fix it.

   It is known that C is lower  level language that PL/I,
it's closer to Assembly. Nothing wrong with it, moreover,
it's why C programs usually are much more efficient.

   BUT 'there is no free lunch' and this effectiveness causes
LESS readability.
PL/I is reacher, so it's is easier to implement things there and
make a code more readable.

Just 2 examples of our NORMAL, REGULAR code (nothing special).

I. Select/Switch statement.
-----------------------
  This important part of ANY *application* program is VERY
        -------
   rudimental and hard to use in C - you can use ONLY numbers here:

switch(my_choice) {
  case 0:
....
  break;
 case 1:
....
  break;
}

You can use Enumerations in C but they are still only NUMBERS.
                                                      -------
 In PL/I you can use any Expression (!) as a switch, that makes a
 code close to specs and easy to read and modify:
      --------------     ------------     ------

Select(Source_Tag);
  When( 'AN' )
        .....
  When ( 'PD', 'PY', 'SO' )
         ...
  When
         ...
  When
         ...
End;

    or something like that

Select;
  When ( SUBSTR(INREC,4,1) = ' ' )
       ....
  When
       ...
  When ( INDEX(UPALPHA,Cur_Tag) > 0  &
         VERIFY(W_TAG23,'0123456789') = 0 )
       ....
  When ( String_1 || String_2 = String_3 )
        ...
End;

It is how SPECIFICATIONS look like, so for a person who works
with this program  FIRST time, it is CLEAR, after reading specs,
what this part of code is doing.
     Just TRY to implement it in C !!!
You will HAVE TO find some 'work around', so it will be further
                                                        ------
from specs and the piece of the code will be much BIGGER and LESS
clear, harder to understand.

   And NUMEROUS parts of C REQUIRE similar 'work around' while PL/I
has such features in it.

Just another example. Strings.

   C has this VERY STUPID limitation - a 'string' in C it's a set of
bytes with x'00' at the end !
But, we have x'00' all over our source data !
For example, we have on-line European Patent Office data (only ONE of
our 400+ *different* applications), and source file is 40 gigabytes (!)
FULL of x'00' !!!

    Also, C does not have Variable Length Strings, that are VERY
important for our *application* programs. Again, this feature helps to
have programs SHORTER, more READABLE, and CLOSER to specs.

  And talking about Readability, ++robin (Feb 26) has some good points:
 > The basic operations of string-handling are done somewhat
 > clumsily in C -- catenation is a simple infix operation
 > in PL/I, but you must use a function in C, and then it
 > catentates the second operand to the first.
 > Nothing like PL/I's c = d || e;
 > (And what happens when, in strcat(s1, s2), the sum of the lengths
 > of s1 and s2 exceeds the declaration for s1?!?!?

NEED WORK AROUND AGAIN !!! Code is BIGGER and LESS CLEAR.

 > again, for comparison, IF s1 > s2 THEN . . .  becomes
 > strcmp(s1, s2) . . . which yields neg, 0, or pos . . .
 > which leads to IF strcmp(s1, s2) > 0 . . .
 > which is scarcely intuitive [shades of the arcane FORTRAN
 > arithmetic IF].

    And now imagine how IT (foo-o-o) looks in OUR programs, where
due to this STUPID x'00' limitation, we even can not use THESE
(not very friendly) functions, and MUST use operations on
BUFFERS, i.e. mem.. functions, taking through a code Length of
buffers all the time !
   Same Program in PL/I is 100 times more readable and is 100 times
more easy to CHANGE and FIX.

So, my points are the following.
  Open Systems people very often tell that *only* C
should be used EVERYWHERE, and it's wrong - you never go to
a farmer's field with a handbag, and to a food store with a truck -
tasks are different, and some can be done better with C,
and some - with PL/I.

   For *application* programming *Production* environment with a lot
of Text Processing, and a lot of *different* and often *changed*
   ---------------                               -----
programs, PL/I is MUCH, MUCH better than C:
 - PL/I has wider set of statements, so it is much easier in PL/I
   to make a code be CLOSE to specs, so next person will understand
   a code faster and can FIX program faster;
 - if a language REQUIRES workaround OFTEN, then it is LESS readable
   than another language that is reacher.

P.S. If you need more language specific information in regards
      to functionality, performance, etc., then read article by
      Eberhard Sturm ( GUIDE & SHARE Conference, 1994 )
          "Power Vs Adventure - PL/I and C".        WWW address is:
http://www.uni-muenster.de/URZ/Mitarbeiter/EberhardSturm/PL1andC.html

--
Paul Gorodyansky      mailto:[e-mail]